The present invention relates to the testing of network environments, and more specifically to a method and system for heterogeneous telecommunications network testing by a plurality of users.
Telecommunications networks have evolved to encompass a variety of services, platforms, applications, data processing system hardware and equipment, referred to as network products. Before deploying network products into a network environment, it is important to first test the network products to ensure their proper operation using devices for testing and for facilitating the testing of telecommunication networks and network products. For example, the SAGE 930A is a test unit that supports a data processing system command interface for performing in-band, or voice-circuit, testing of network products. A software application that executes in a computer can be used to drive the SAGE 930A through a serial connection. Additionally, with the proliferation of out-of-band (non-voice) ISDN and SS7 implementations in telecommunication networks today, additional types of test units such as the Ameritec AM2 Niagra, Telesynch 1567, and HP500 IDACOM are available to test out-of-band signaling transactions of a telecommunications network. These test units can also be driven by a data processing system software application that communicates to the test unit via commands over a serial connection.
A problem with such test devices is that they typically require a command interface which is dedicated to accomplishing a narrowly defined particular test objective and is therefore both cumbersome and time consuming to use. Batch files which automate a series of commands from a data processing system to the test device can be used to alleviate this problem with test devices; the use of batch files do not require data entry of command to the connected test device. A single batch file, or small set of batch files, which contains all the commands necessary to accomplish a particular test objective is invoked. The user is then free to perform other tasks while specific testing is automated.
Still other test improvements have been made through the advent of a graphical user interface (GUI). Programmers have created GUIs to make use of test devices user-friendly. Complicated test scenarios that would otherwise require many commands, or a multiplicity of synchronized batch files, are now achieved through a simple user interface method. Mouse selections, menu options, buttons, drag and drop techniques, and other GUI methods, are provided for enhancing the quality and efficiency of performing telecommunications network testing.
Local Area Network (LAN) technology and communication architectures have also enhanced the testing of network products. GUIs are conveniently located, either locally or remotely, to a particular data processing system that drives the actual testing of network products. This methodology is referred to as client/server technology. The GUI is an application, referred to as a client, which executes on a system in the network. A software application that satisfies requests of a client is referred to as a server. The server also executes on a system in the network. The client/server framework preferably allows a client to be located on any system in the network, even on the same system on which the server resides.
The server traditionally synchronizes a multiplicity of clients-to-server functions, but there are many problems with synchronization within a telecommunications network test environment. Resources, such as available trunks, switches, automatic response units, automatic call distributors, credit card validators, network technology, etc., that are needed by one type of test may circumvent completion of another type of test, which needs the same resources. The server must properly synchronize test requests to the various resources available at the time of the test request.
With many varieties of network products and methodologies for testing of network products currently available, test devices must be proficient in testing a great number of applications and the many varieties of test cases associated with these applications. Thus, a test device has to be capable of learning new test case formats and new test interfaces as required. A test case defines how a particular test will be performed. For example, a test case may simply be a batch file which performs a test, or a test case may be a file of commands or directives maintained with a GUI. Additionally, a test case may be a memory structure which is built by a data processing system upon use of a client or other application. Whatever the embodiment, a test case embodies the action which will take place in order to perform a test.
Yet another problem is managing a multiplicity of tests to be performed on a limited number of test devices. Test labs may have limited test device equipment so testers typically share the test equipment. Human maintained schedules have been deployed which correspond to network configurations that are to be in place according to that schedule. While there have been some automated synchronization techniques provided, there is currently no method and system for synchronizing all testers of a heterogeneous lab environment with the test that will be performed in the laboratory. Currently, all types of test that can be performed in telecommunications are accomplished with a plethora of applications, systems, test case types, and methods.
Therefore, there is an unmet need in the art for users in a network environment to be able to share test cases and the results of executed test cases on the network. This need extends to all the test environments in the network environment, such as all the tests available in an entire testing laboratory. Furthermore, there is an unmet need in the art to allow a single user in the network environment to perform an arbitrary test case or to perform any type of test case that can be performed in an entire laboratory. Additionally, there is an unmet need to be able to perform any type of test case without knowing the test case formats and methodologies of each and every test case available for execution on the network.
The present invention involves a method and a system for heterogeneous network testing by a plurality of users. It requires at least one client machine, an execution server, and at least one custom server in a local area network (LAN) or wide area network (WAN) environment for heterogeneous network testing in which one or more client machines communicate with the execution server which in turn manages one or more custom servers that execute requested test cases. The custom servers may be of various types, including ISDN servers, SS7 servers, and CG servers. A user on the network communicates to a client machine via a graphical user interface (GUI) to determine which test case or test cases are to be executed. The requested test cases are retrieved and may be edited by the user on the client machine prior to communicating the test case information from the client machine to the execution server which coordinates the execution of test cases by an appropriate custom server. The results of the executed test case are stored and made available to other users on the network.
The client machine includes a GUI for performing tests on a variety of equipment using a variety of test cases. The client machine provides authentication abilities to ensure validation of users. The GUI of the client machine provides a user-friendly interface for managing test cases and for conveniently maintaining (e.g. create, change, delete, store, access, etc.) test cases of new or existing platforms by the client machine, a generic test case can be maintained thereafter. The generic test case is easily directed to an arbitrary environment for performing a test. The client machine has access to file servers containing test cases and database servers for access to test cases. The client machine manages its own set of generic test cases locally or through its own file servers. Multiple users can share test cases maintained by the present invention through their respective client machines to shared file servers.
When a test case is ready for execution, the user selects a single test case or a plurality of test cases for either interactive execution or scheduled execution of the test case. An interactive execution allows the user to see the results of the executed test request as they become available, i.e. xe2x80x9creal timexe2x80x9d. The results of the executed test are made available to the user before the client machine performs any other functions. When the results of the executed test are provided to the user, they are also provided to a correlated test output file where they may be later retrieved for perusal at some later time. A scheduled execution, on the other hand, runs a background task and is therefore transparent to the user. The results of the executed test will only be directed to the correlated test output file for convenient perusal at some future time. The user may specify to run the request now or at a later scheduled time.
For every test requested issued from a client, a priority is assigned to that test request before being transmitted to the execution server. The execution server manages the request according to the priority of the test requested and other tests in progress. The execution server supervises prioritization and scheduling of test requests from all client machines on the network. The execution server accesses information about which lab resources are to be used for specific types of test requests in accordance with presently available test resources. The information available to the execution server includes information about which custom server the execution server must transmit the test request to in order to perform the requested test(s) and which circuit(s) on which trunk(s) will be used to perform the telecommunications activity associated with the test request(s). Thus, the information available to the execution server allows network resources to be preallocated for certain types of tests. It is the responsibility of the execution server to synchronize all client machines that requested test cases to the currently available resources. The execution server also performs loop through tests prior to testing to assure that resources are actually available, i.e. not in error or failure.
The execution server is the supervisory server for platforming all requested test cases in the lab environment. Thus, execution server conveys protocol for successful completion of test request(s) to custom servers that ultimately perform the requested test case(s). The execution server also manages the optional step of retrieving appropriate billing information upon execution of the requested test cases and then matching associated billing information with the appropriate test case results. The billing information of executed test cases may be accessed if desired by the user.
A custom server is responsible for performing specific types of test cases. A custom server may have a plurality of test devices connected to it, or it may be directly connected to the environment that it will test. Typically, a custom server receives and executes one type, or one category, of test cases. For example, one custom server may handle all ISDN test cases. Another custom server in the network may handle all SS7 test cases. Yet another custom server may handle all test cases for a particular manufacturer of connected test devices. There may be many custom servers in the network, each of which handles some set of test cases as logically determined by a person who has knowledge of how best to plan use of a telecommunications network lab. The physical layout of the lab topology may be optimized by appropriate use of custom servers on the telecommunications network.
Each custom server test execution is limited by the execution server. The custom server performs test cases and saves test results of the test case that it communicates back to the execution server. A custom server may include a graphical user interface (GUI) that provides tracing mechanisms and service manager support functions dependent on the type of custom server and its processing. In one embodiment, the custom server manages a client""s interactive test request embodiment, the custom server completes the test case and the test output, communicates status back to the execution server, and then the execution server communicates output back to the client.